1. Field of the Invention
The present invention relates to the field of digital system design verification. More specifically, the present invention relates to design verification of digital systems whose development efforts are neither hardware nor software dominant.
2. Background Information
The majority of digital systems being designed today are task specific embedded systems that consist of standard and/or custom hardware as well as standard and/or custom software. Standard hardware typically includes off-the-shelf microprocessor/micro-controller, and memory etc., whereas custom hardware is implemented with programmable logic devices (PLDs), or Application Specific Integrated Circuits (ASICs). Hardware architecture binds and constrains these resource and provides a framework on which software processes execute. Standard software typically includes a real time operating system (RTOS), and configurable device drivers, whereas customer software is the embedded application. Software architecture defines how these processes communicate. The complexity of these embedded systems varies widely from low to high end depending on the market segment and product goals. They can be found in almost everything that we encounter in our daily lives, such as communication systems ranging from the phone on our desk, to the large switching centers, automobiles, consumer electronics, etc.
Some embedded systems are software dominant in their development effort, in that most of the design efforts are focused on implementing the functionality in software. Typically, standard or previously designed hardware are employed. Thus, even though the software dominant characteristic typically makes these systems a lot more cost sensitive, these systems can be readily validated by compiling and debugging the software under development on existing hardware, using a compiler, a debugger and other related software tools.
Other embedded systems are hardware dominant, in that most of the design efforts are focused on implementing the functionality in PLDs or ASICs. The original software content of these systems tends to be small. Typically, these embedded systems are found in applications where performance is critical. For these systems, hardware emulation and/or simulation techniques known in the art appear to adequately serve the design verification needs. In the case of emulation, the hardware is xe2x80x9crealizedxe2x80x9d by configuring the reconfigurable logic and interconnect elements of the emulator. The configuration information are generated by xe2x80x9ccompilingxe2x80x9d certain formal behavioral specification/description of the hardware. In the case of simulation, a simulation model would be developed. For the more xe2x80x9ccomplexxe2x80x9d hardware, since it is very difficult, if not outright impossible, to model all the behaviors of the hardware, certain accuracy are often sacrificed. For example, in the case of a microprocessor, it is often modeled by a xe2x80x9cbus interface modelxe2x80x9d, i.e. only the different bus cycles that the processor can execute are modeled. The modeled bus cycles are driven in timed sequences, representative of typical bus transactions or bus activities for invoking specific conditions.
Embedded systems that are most difficult to validate are those that are neither software or hardware dominant, in that both parts play an equally important role in the success of the system. Due to increased time to market pressures, hardware and software are usually developed in parallel. Typically, the hardware designers would validate the hardware design using an hardware simulator or emulator. Concurrently, the software designer would validate the software using an instruction set simulator on a general purpose computer. The instruction set simulator simulates execution of compiled assembly/machine code for determining software correctness and performance at a gross level. These instruction set simulators often include facilities for handling I/O data streams to simulate to a very limited degree the external hardware of the target design. Typically, instruction set simulators run at a speeds of ten thousand to over a million instructions per second, based on their level of detail and the performance of the host computer that they are being run on.
Traditionally, the hardware and software would not be validated together until at least a prototype of the hardware, having sufficient amount of functionality implemented and stabilized, becomes available. The software is executed with a hardware simulator, and very often in cooperation with a hardware modeler (a semiconductor tester), against which the hardware prototype is coupled. The hardware simulator provides the hardware modeler with the values on the input pins of the prototype hardware, which in turn drives these values onto the actual input pins of the prototype hardware. The hardware modeler samples the output pins of the prototype hardware and returns these values to the hardware simulator. Typically, only one to ten instructions per second can be achieved, which is substantially slower than instruction set simulation.
Recently, increasing amount of research effort in the industry has gone into improving hardware and software co-verification. New communication approaches such as xe2x80x9cmessage channelsxe2x80x9d implemented e.g. using UNIX(copyright)xe2x80x9cpipesxe2x80x9dhave been employed to facilitate communication between the hardware and software models (UNIX is a registered trademark of Santa Cruz Software, Inc.). Other efforts have allowed the models to be xe2x80x9cinterconnectedxe2x80x9d through xe2x80x9cregistersxe2x80x9d, xe2x80x9cqueuesxe2x80x9d, etc. In U.S. Pat. Nos. 5,771,370 and 5,768,567, an optimizing hardware-software co-verification system was disclosed.
Notwithstanding these advances, the fundamental fact remains that a rather detailed hardware model is required before it is possible to verify software concepts within the hardware context. As a result, the concurrent development of hardware and software have to proceed without the ability to verify the interfaces between the hardware and software being contemplated. Furthermore, without such verification, the partitioning choices on what is to be implemented in hardware versus software have become increasingly more difficult as the complexity of the embedded systems continue to increase.
To address this problem, the industry looks to higher level of abstraction to describe the hardware components, i.e. describing the hardware components only in terms of their functionality and not their implementations. These high level models are commonly referred to as xe2x80x9csystem modelsxe2x80x9d, and are executed within a system or transaction level simulator, which typically executes 10-100xc3x97 faster than historical simulators that operate with a lower level of abstraction. With the enhanced execution rate, these system or transaction level simulators are much more capable of keeping up with the simulators employed to execute the software.
However, these system or transaction level simulators have not gained wide acceptance because the combined performance has been constrained by the communications between the simulators. As the general performance of the simulators increases, the performance of the synchronization and transfer of information between the simulators become even more important.
A successful synchronization strategy must ensure the consistency of the verifications, i.e. for a fixed set stimulus, the verification results must always be the same. Preferably, it should allow both verifications to proceed concurrently, without impeding performance. Furthermore, it should allow either verification to operate as a source or sink for information, and it should be flexible in the resolution of synchronization periods. Prior art synchronization strategies typically require either verifications to be performed in locked step, resulting in substantial degradation in software verification performance, or employ roll back mechanism, which imposes significant memory hardware burden on the co-verification system. Thus, an improved approach to co-verification synchronization is desired.
Hardware and software of a system is co-verified with synchronization events generated in the respective hardware and software verifications being accumulated and provided to the other verification on a periodic basis. The faster verification is halted to allow the slower verification to catch up, upon expiration of a synchronization window. Once caught up, the accumulated synchronization events are provided to the respective other verification. The transferred synchronization events are then in turn injected into the other verification at the same offset time into a synchronization period the synchronization events occurred in the previous synchronization period.
In one embodiment, a co-verification coordinator is provided with a flow detector, a synchronizer and a configurator to facilitate practice of the present invention. The flow detector includes logic for monitoring, detecting, and accumulating software synchronization events. The synchronizer includes logic for halting the faster (software) verification, and detecting whether the slower (hardware) verification has caught up. The synchronizer further includes logic for transferring the software synchronization events accumulated by the flow detector to the hardware verification for subsequent injection into the hardware verification, as well as receiving and forwarding hardware synchronization events accumulated by the hardware verification to the flow detector for subsequent injection into the software verification. Finally, the configurator includes logic to facilitate configuration and reconfiguration of the synchronization window size.